home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group01a.txt
/
000101_icon-group-sender _Mon Jul 10 08:02:48 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2002-01-03
|
5KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20447
for icon-group-addresses; Mon, 10 Jul 2000 08:02:40 -0700 (MST)
Message-Id: <200007101502.IAA20447@baskerville.CS.Arizona.EDU>
Date: Mon, 10 Jul 2000 16:51:56 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU
Subject: Re: Error messages
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 4073
I wrote:
> I just _have_ to ask: WHICH hassle?
Gordon Peterson wrote:
I've written a **lot** of such stuff (admittedly in
SNOBOL/SPITBOL rather than Icon, but the principle is certainly
similar). I don't think you have anything like the same capabilities
and ease of programming in Prolog that you have in S*BOL or in Icon.
I've been a SNOBOL user off and on since the mid-70s.
I still use SNOBOL on UNIX, quite happily.
One of the first things I did when I met Prolog was to figure out
the equivalents in Prolog. It used to surprise people when I pointed
out that there was prior art for "!" in SNOBOL's FENCE.
The thing is that SNOBOL gives you *almost* but not quite the same
power and convenience for parsing text as Prolog does, but there it stops.
As an anthropologist pointed out to me in the mid-70s when I was trying to
persaude everyone to use SNOBOL, "if it can't parse anything but strings,
what's the big deal?" Icon is a step backwards for parsing strings, but a
big step forward for matching other kinds of data structures. But even
Icon has a long way to go to match the ease of programming in Prolog.
Now it could be that you don't program in S*BOL or Icon the way I do, or that
maybe you'd just rather do it (for whatever perverse reason) in Prolog. Hey,
whatever floats your own personal boat...
You don't have to be perverse to prefer Prolog.
You just have to like being able to use labelled trees as data structures
and the ease of pattern matching on them.
Seriously, the two big differences between Icon and Prolog here are
- Icon has assignment statements, Prolog doesn't.
- Icon looks a lot like C, Prolog doesn't.
It's the other areas surrounding the project where the real
benefits show up.
Which areas, exactly? That's really what this thread is about.
Generating binary output as such isn't a problem in Icon _or_ Prolog.
I've identified "figuring out what the output structure is" as a problem.
The script compiler I wrote for the French Social
Security Administration was written in a day and a half, and produced
the most beautifully complete and detailed listings (cross references,
formatted symbol tables, error summaries, and even a listing table of
contents) you ever saw. It would have taken at least six months to
write the same thing in C/C++, and maybe not a whole lot less to have
written it in Prolog.
Can you give any *reason* why it would have been hard in Prolog?
> Writing the output is the tricky part. The real hassle is finding out what
the wretched output is supposed to look like.
I claim that THAT is only part of the hassle too.
My point is that it is a *major* hassle, given the state of the documentation,
and that it is a *language-independent* hassle.
But hey, as I said, I've got
better things to do than to go through a detailed point-by-point argument with
you if you really want to do it in Prolog
This is an Icon mailing list, and "what language features help or hinder
for this kind of task" is *exactly* what this thread is about.
Surely you have better things to do than hurling around unjustified
(and unjustifiable) insults against other programming languages.
Shouldn't explaining *how* Icon helped you so much be one of them?
> For UNIX (maybe Windows too; I've never used Cygwin) anyone wanting to write
a new kind of assembler would be mad not to re-use as much of the GNU binutils
as practical. By all means put a smart new front end on an assembler, but
let someone else deal with the *real* hassle.
Well, I guess it depends on whether you want an assembler that works like
everyone else's or not. (Buf if you're happy with existing ones, why write a
new one at all?)
This is a rather strange comment. The original question came from someone
who wanted to do a new kind of analysis of the input. Nothing was said
about wanting to produce incompatible binary object files. If it is to be
useful, presumably that person *does* want an assembler whose *output*
conforms to the same interface requirements as everyone else's.